Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Sign rework api (part 1 of 2 for sign rework PR) #706

Open
wants to merge 56 commits into
base: main
Choose a base branch
from

Conversation

DerToaster98
Copy link
Contributor

Describe in detail what your pull request accomplishes

As discussed with @oh-noey the original PR (#679 ) is being splitted into two parts.
The first part (this PR) being the necessary API classes and changes ONLY.

That contains the base classes for all signs as well as their registration and the sign wrapper shenanigans.

This does not yet contain the necessary changes to TranslationTask.java and RotationTask.java as those changes need to be looked at again. Most of the change is switching to a call to the signListener instance though.

Checklist

  • Tested
  • Performance tested (Could improve performance, but mainly makes the sign behaviors extendalbe and overridable in a nicer way. Also reduces duplicate code)

(cherry picked from commit 5248bc2)
(cherry picked from commit 960b30a)
(cherry picked from commit 7f46895)
(cherry picked from commit 39e08a5)
(cherry picked from commit d5ded2e)
(cherry picked from commit 9b7ea60)
(cherry picked from commit aff2a1d)
(cherry picked from commit 48a9bc1)
(cherry picked from commit dc85f9d)
(cherry picked from commit ca35cd3)
(cherry picked from commit 464fcd6)
…again

(cherry picked from commit a307803)
(cherry picked from commit b65562e)
(cherry picked from commit 132f179)
(cherry picked from commit 453b0a5)
(cherry picked from commit ce7f379)
(cherry picked from commit d70b65b)
(cherry picked from commit e2bae7d)
(cherry picked from commit d86b510)
(cherry picked from commit 2df0385)
Copy link
Contributor

@TylerS1066 TylerS1066 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did an initial look through, to properly understand the AbstractMovecraftSign I think I'll need to try my hand at updating a sign or two.

Comment on lines +17 to +18
// DONE: In 1.21 signs can have multiple sides! This requires us to pass the clicked side through or well the relevant lines and the set method for the clicked side => Resolved using the SignWrapper
/*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean a two-sided sign effectively acts like two signs to Movecraft?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, each side can have different text, which makes each side act as individual side.

So basically it would be like putting two one sided signs with their backs to each other.

I would like to keep it like this, it's useful for hanging cruise signs or for peripheral stuff like contacts and Status

* - SignChangeEvent
* - PlayerInteractEvent, if the clicked block is a sign
* - CraftDetectEvent
* - SignTranslateEvent (if the sign is a subclass of AbstractCraftSign)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overhead of the Bukkit event system is significant when translating signs. Is it possible that this system could replace it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ya, i could change it so it has a "onTranslate" function in the base class. I'd still make it collect "all the same signs" per type and then calling their "instance", so in effect what it does right now, but without the bukkit event being the "bridge".

Comment on lines 111 to 117
public void onCraftDetect(CraftDetectEvent event, AbstractSignListener.SignWrapper sign) {
// Do nothing by default
}

public void onSignMovedByCraft(SignTranslateEvent event) {
// Do nothing by default
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need these?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those implementations? Not really, but the functiosn should be there as at least abstract. I use the CraftDetectEvent callback to handle stuff like setting the name, displaying the Status and so on on mount (latter is not fully working yet but eventually)

The other is just the callback for when the sign was moved by the craft, updating stuff and such.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will leave them in as that for now. Not all craft signs require them but we should give the opportunity to react to that

Comment on lines 123 to 126
/*if (signWrapper.block().getBlockData() instanceof Directional)
craft.setCruiseDirection(CruiseDirection.fromBlockFace(((Directional) sign.getBlockData()).getFacing()));
else
craft.setCruiseDirection(CruiseDirection.NONE);
craft.setCruiseDirection(CruiseDirection.NONE);*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove commented out code, Git keeps it around.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, will do that when i work on the fork again

@DerToaster98
Copy link
Contributor Author

I did an initial look through, to properly understand the AbstractMovecraftSign I think I'll need to try my hand at updating a sign or two.

For examples on the implementations you can just check the (older) PR which also has the implementations (#679 ) or the testbranch in my fork

*/
public abstract class AbstractMovecraftSign {

private static final Map<String, AbstractMovecraftSign> SIGNS = Collections.synchronizedMap(new HashMap<>());
Copy link
Collaborator

@oh-noey oh-noey Sep 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this whole registry system outside of the actual AbstractMovecraftSign implementation, and use a singleton instead of static? Perhaps a MovecraftSignRegistry? we can make it accessible from the Movecraft instance for now. With our move towards DI/inversion of control, we should avoid adding new static singletons like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once it's merged. We already have some registry thing used in the DataTags topic, so if we add a generic registry implemtnation (i have one somewhere) we should adjust that too

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think a generic registry is a good idea - its just a naming convention. I just would prefer to seperate the registration system from the registrars

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant a generic registry base class

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a small generic registry base class that can be used for multiple registries, does it fit your needs?

(cherry picked from commit fd70b50)
@DerToaster98
Copy link
Contributor Author

Adressed your points

(cherry picked from commit 54336e5)
(cherry picked from commit f7fd65e)
(cherry picked from commit 6a09a70)
(cherry picked from commit 8e7f1bf)
(cherry picked from commit a426bcf)
(cherry picked from commit c345a25)
(cherry picked from commit 834794f)
(cherry picked from commit 2454f78)
(cherry picked from commit dc459d2)
(cherry picked from commit 77bb394)
(cherry picked from commit 441452c)
(cherry picked from commit 0433e31)
@DerToaster98
Copy link
Contributor Author

PR is ready for new review, it is now at the same state as my own testing branch which is being run since 2 weeks on a different server and so far works good

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants